到了今天，以經過了一半的鐵人賽，這次比上次還要久，現在說說目前遇到的狀況及心路歷程。我絕對不會說是因為拖了太久的「待續文」，今天想要偷懶一下！

其實這次主題，一直是心中想要學的項目。開始從事相關工作以來，也已經從一個菜鳥變成一個中鳥（？），不學學點特別的，無法跟下面的人說嘴教導。其實一直覺得Unit test（單元測試）是個很酷的東西，因為自己先前測試都是一連串的動作：上傳檔案➞存到server➞取得檔名➞比較檔名，每次有新的功能加入，或是調整，就要執行多次，而且還要自己準備很多不同的檔名的檔案，而且檔案不能太大，太大要上傳很久。雖然在網路上有看到Unit test相關的事情和TDD，但是完全沒有感受。直到遇到高手同事，才知道他們都有寫Unit test的習慣，雖然涵蓋率*不是100%，但也有50%以上，這時才知道原來Unit test還滿多人使用的。
因此下定決心要學習Unit test，所以先前就買了《The Art of Unit Testing》，可是卻遲遲沒有進度，因此才在這兒用力的推自己一下。

回到正題，走到了第17天，主要的基本功能都已經說的差不多（雖然有兩三篇的程式碼一直都還沒有整理完，push上來），像是stub和mock，還有一些作者認為的程式寫法，都大概說明過。所以可以做基本的處理。
這幾天有稍微使用在工作上，深深的體會到，現實場景與跟隨著書前進是不一樣的。首先，我們程式裡面包含眾多的功能，而書中都是一步一步的蓋起程式碼城堡。但是現實面是：快速的達到目標。先打地基，同時要材料搬到旁邊，蓋城牆時，也順便把大砲放在牆頭上。許多事情都是一起進行，很難可以給自己有時間寫出漂亮的Unit test。
經過那次嘗試的經驗，可以知道自己對於程式功能的切割還不是很透測，所以導致Unit Test很難寫出自己想要的測試內容。但是，在寫Unit Test的時候，會思考自己的程式應當如何寫，以及會有怎樣的預期內容。經過思考後，就會開始整理自己的程式碼，讓他變得更完整且簡便。雖然這樣僅有一兩個小功能，但是也足以讓我衝擊，發現果然跟隨著大師前進，受益良多。這本果然要好好的啃下去。

在這本書可以學到如何切割出程式，寫出比較精簡的程式碼（作者沒深入探討，詳細資料還是要參考別人的著作）。但這個距離還是離我們太遠，這樣會讓我們一頭燒Unit Test，另一頭燒精闢程式碼。
所以近期有稍微研究一下別人寫的文章，比較多實戰說明，像是本屆鐵人賽的TDD教學：TDD - 紅燈，綠燈，重構，30天 TDD之路有你有我或是在網路上看到還滿清楚的教學文：30天快速上手TDD，這些都是有經驗的前輩們寫出來的文章，比我的寫還要更清楚且實用XD 大家可以多多參考。

註：
涵蓋率：就是指Unit Test可以測試程式中在整個程式的比例，越高表示越好，代表幾乎所有程式都可以被測試檢查是否正常運作。當然寫越多會花費越多時間，但是TDD可以解決這個問題（吧XD）。現在IDE大都可以進行估算，可以來看看自己的Unit Test寫得如何囉